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Three Aids To Improved Network Operation 
Scheduled Software Maintenance 


As the ARPA Network has grown larger, we have found it difficult to 
find times when necessary new software can be slipped into the 
network without disrupting anyone. For instance, there is always 
intrasite traffic between the machines at MIT, and there is almost 
always traffic between the AMES TIP and IMP--the sun never sets on 
the ARPA Network. To minimize unscheduled disruptions and to 
simultaneously let us do what we have to do, we propose to schedule 7 
A.M. - 8 A.M. eastern time every Tuesday as a time when the IMPs can 
be reloaded. We will probably not use this period every Tuesday, but 
we do reserve this period every Tuesday. The above period is in 
addition to the several hours a month already scheduled at each site 
for hardware preventative maintenance. 


Because a network user may not know when his machine is scheduled for 
maintenance or because he may forget and work through the Tuesday 
morning software period, we propose to generalize the IMP-Going-—Down 
IMP-—to-Host control message so it may be used to remind the user. 
This message (described in detail below) will contain information 
that the IMP is going down in m times five minutes, for n times 5 
minutes, for a given reason. Hosts (and the TIP) should use this 
information to remind all their Network users that the IMP will be 
going down after the stated interval. 


Occasionally there is an emergency reason for restarting or reloading 
an IMP. For instance, while three Hosts at a site are functioning 
well, one Host cannot communicate with the IMP. This sort of 
situation sometimes requires the IMP to be restarted. Such a restart 
will be preceded by several minutes by an IMP-Going-Down Message to 
allow working users to save their work in such a way that they can 
restart once the IMP is back up. 


In both of these cases, as well as cases where an IMP is performing 
so poorly that is must be shut down quickly, a type 2 IMP-to-HOST 
message will be transmitted to the HOST about 30 seconds before the 
IMP goes down. Finally, of course, there may be occasions when the 
IMP crashes so quickly that no warning is given, but the IMP will 
never be intentionally shut down in this way. 
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2g 


IMP-to-Host Communication 


There have long been complaints that the IMP-to-Host error messages 
were not precise enough or were just plain ambiguous. In RFC #312 we 
proposed some additional error messages. These and other IMP-to-Host 
message changes will be made on August 14, 1972 and we encourage 
Hosts to modify their NCP’s as appropriate by then. Unmodified NCPs 
will probably continue to work after this change, but each site 
should look into this question carefully. The table below lists all 
the IMP-to-Host messages and clearly indicates the changes which will 
be made. 


Type Old Meaning New Meaning 
0 Regular Messages Same 
1 Error without Error in Leader of Host-to- 
identification IMP Message 


Bits 31,32=00 - IMP’s 
error flip-flop set on 
the first 32 bits of a 
Host-to-IMP message which 
the IMP therefore cannot 
identify 

Bits 31,32=01 - Host-to-IMP 
message too short (less 
than 32 bits) 

Bits 31,32=10 - illegal 
Host-to-IMP code 


2 IMP Going Down IMP Going Down 

Bits 17-32 coded as follows: 
All bits zero - going down in 
30 sec. 

Bits 17,18=01 - scheduled 
hardware PM 

Bits 17,18=10 - scheduled 
software reload 

Bits 17,18=11 - emergency 
reload or restart 

Bits 19-22 - how soon the 
IMP is going down - in 
5 minute units 

Bits 23-32 - how long the IMP 
will be down - in 5 
minute units 


3 Blocked Link Unassigned 
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NOF 


RFNM 


Link Table Full 


Destination Dead 


Same 
Same 
Unassigned 


Destination Dead 


26 July 1972 


Bit 32=0 - the destination 
IMP is dead, or cannot be 
reached, or does not exist 
Bit 32=1 - the destination 
Host is dead or does not 
exist 


Error in Data of Host-to IMP 
Message 
IMP’s error flip-flop set 
on the data bits of a Host- 
to-IMP message identified 
by the given source and link 


8 Error with identi- 
fication 


9 Incomplete Transmission Incomplete Transmission 
Bits 31,32=00 - the destination 
Host did not take the message 
for a long time 
Bits 31,32=01 - Host-to-IMP 
message too long (more 
than 8095 bits) 
Bits 31,32=10 - Host-to IMP 
message too slow. The 
last message took more 
than 15 secs. between 
the first bit and the 
last bit, and was discarded 
Bits 31,32=11 - Host-to- 
IMP message lost in the 
subnet 
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10 Unassigned IMP-Host Interface Reset 
The IMP’s ready line has 
been dropped and pending 
output to the Host discarded 
(probably because the Host 
has not taken messages from 
the IMP for a long time). 
The IMP will return a type 1 
message of subtype 0 at the 
completion of the next Host- 
to-IMP message. 


These changes can be summarized as follows: 


1. There is now one and only one IMP-to-Host message in response to 
each Host-to-IMP regular message. 


2. Message types 1, 2, 7 and 9 now carry additional information. 
3. Message type 10 has been added. 
4. Message types 3 and 6 have been discarded. 
3. Network News Service 
We have instituted a Network news service. TIP users get the news by 
typing the TIP command @NEWS. Users of other Host can get the news 
by ICPing to socket 15600031 (octal) at the BBN Tenex. 
If you have further suggestions for improving the operation of the 


Network, we request your comments. 


[ This RFC was put into machine readable form for entry ] 
[ into the online RFC archives by Lorrie Shiota 08/00] 
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